FIG. 1 is a diagram of a conventional multithreaded computer memory 2 connected to first and second data processors 3 particularly identified as first and second processors 3a and 3b. Multithreaded computer operations can however be implemented with a single data processor as well. Multithreaded computer systems are disclosed in U.S. Pat. No. 5,515,538, "Apparatus and Method for Interrupt Handling in a Multi-threaded Operating System Kernel," granted in 1996 to inventor Steven R. Kleiman and assigned to Sun Microsystems, Inc., of Mountain View, Calif. That patent is hereby expressly incorporated hereinto and made a part of the present application. computer memory 2 includes a user level memory region 2a and a kernel level memory region 2b. A multithreaded computer memory is a computer memory on which multiple threads are being executed. A thread is an independent program code execution sequence. User level memory region 2a is shown possessed by a plurality of threads 5 including thread 5a through thread 5f, a threads library 8, a data element 9, and a mutex (i.e., mutual exclusion) lock 9a. Kernel level memory region 2b is shown possessed by a plurality of light weight process 12 and a run queue 14. Data element 9 is code or information required for processing by a particular thread. The plurality of light weight processes 12 includes light weight processes 12a-12d. Threads library 8 is a mechanism for scheduling individual ones of threads 5 onto particular ones of light weight processes ("LWPs"). A scheduled thread blocks other threads from running on an associated LWP until the scheduled thread has completed running through its execution sequence. For details regarding threads and light weight processes, see for example Programming with UNIX Threads by Charles J. Northrup (John Wiley & Sons, Inc., 1976), pp. 4-6. Briefly, light weight processes are kernel entities which are scheduled to run entirely within a kernel level memory region 2b. Threads 5 are scheduled at user level memory 2a onto LWPs 12. Particular LWPs 12 are in turn scheduled onto particular ones of processors 3. Run queue 14 contains information for scheduling LWPs 12 onto multiple processors 3a and 3b. For example, of six threads 5a-5f which FIG. 1 shows, only four threads 5c-5f are shown scheduled onto corresponding four LWPs 12a-12d. Further, of four LWPs 12a-12d, only two LWPs 12c-12d are scheduled onto respective processors, 3a and 3b. User level memory 2a further includes a multiple exclusion lock (i.e., mutex) 9a associated with data element 9. Thread 5f of user level memory 2a is shown connected by line 9a ' to mutex lock 9a to represent that thread 5f owns mutex lock 9a momentarily and that no other thread can access data element 9 while the owning thread runs. Line 9a ' suggests that the execution sequence of thread 5f is dependent on data element 9 which is protected by mutex lock 9a.
Unfortunately, the run status of light weight processes is not available within user level memory region 2a. This presents a technical problem which is desirably overcome. Accordingly, when a thread which has been scheduled onto a particular LWP seeks to acquire a particular lock and access to data associated with the particular lock, the thread waits for the associated light weight process to complete executing its current scheduled process whether the current light weight process is already running or whether it shows no indication of running in the future. Priority inversion of threads thus results when the scheduled threads are spinning for excessive periods of time waiting for a prior light weight process to complete execution. Such waiting may block timely scheduling of higher priority threads.